Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require JavaInfo on deps, move scrooge srcjar to srcs #523

Merged
merged 9 commits into from
Jun 20, 2018

Conversation

johnynek
Copy link
Member

since we put the scrooge srcjar into deps, we wind up putting all the srcjars as well as the thrift srcs on the classpaths. This is not what we want.

I am having trouble using this rule in a repo with a very large number of thrifts because the classpaths are getting too large. I will do a run with this and see if it bypasses.

cc @ianoc @ittaiz

@johnynek
Copy link
Member Author

while this is still probably good, this did not solve my problem. somehow, the thrift jars are still showing up on the classpath.

@ittaiz
Copy link
Member

ittaiz commented Jun 16, 2018 via email

@johnynek
Copy link
Member Author

it is a short review, not much to it, but I don't think we should merge it if it does not improve matters.

I'll try to write a test that asserts that the thrifts don't end up on the classpath.

Meanwhile: bazelbuild/bazel#5413 seems to let me bypass (at the expense of very long startup times due to the quadratic algorithm that bazel uses to construct the jars for long classpaths).

@ittaiz
Copy link
Member

ittaiz commented Jun 16, 2018

I'll leave this to @ianoc since I'm not sure I understand the change (it seems you're just passing the srcjar in a different way)

@ianoc
Copy link
Contributor

ianoc commented Jun 16, 2018

this change lgtm

scala_library(
name = name,
srcs = [srcjar],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this work? i think the scala_library rule is restricted to only allow actual files in the srcs not targets?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(or does it intelligently realize the output file?... interesting)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it does use the output file here. We could be more precise and just list the output filename. That might actually solve the problem.... Maybe by putting the whole target we are sucking up all the deps.

@ittaiz
Copy link
Member

ittaiz commented Jun 16, 2018 via email

@johnynek
Copy link
Member Author

okay, @ittaiz @ianoc can you take a look?

Basically, I removed all the old crufty hacks we had and just require java providers in all places. With this, we don't mistakenly put a bunch of irrelevant stuff on the path. I added a test that we don't add the thrift jar.

This is a bigger change, but takes us towards removing tech debt, so it seems like a win.

@johnynek johnynek changed the title move scrooge srcjar to srcs Require JavaInfo on deps, move scrooge srcjar to srcs Jun 20, 2018
Copy link
Member

@ittaiz ittaiz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good in general.
Please see some comments inside.

scala/scala.bzl Outdated
@@ -12,6 +12,11 @@ load(
"@io_bazel_rules_scala//specs2:specs2_junit.bzl",
_specs2_junit_dependencies = "specs2_junit_dependencies")

load(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftover?

@@ -26,15 +26,12 @@ def _collect_jars_when_dependency_analyzer_is_off(dep_targets):
runtime_jars = []

for dep_target in dep_targets:
# we require a JavaInfo for dependencies
# must use java_import or scala_import if you have raw files
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why keep the “if”? I think you can require the divider on the signature of the attribute and so throw all of the conditionals away

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because scrooge puts everything in the deps sadly... we want to fix it, but one step at a time.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

scrooge macro puts all the thrift dependencies on the deps. :( we need #510

#!/bin/sh

if grep -q $1 $2 ; then
echo "ERROR: found $1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add what was expected? Either in the assertion or in the test name since 6 months from now I won’t remember :)

extra_information=_collect_extra_information(ctx.attr.deps),
# unfortunately, we need to see this for scrooge and protobuf to work,
# but those are generating srcjar, so they should really come in via srcs
extra_information=_collect_extra_information(ctx.attr.deps + ctx.attr.srcs),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m sorry but I don’t understand this. Where does scroog euse this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

search for all the extra information in the file. For instance: https://github.com/bazelbuild/rules_scala/blob/master/twitter_scrooge/twitter_scrooge.bzl#L85

Really this is something that should be replaced with #510 but that is staged behind a few layers of tech debt removal (a supported skylark function to compile scala and get a JavaInfo, and a toolchain that sets up all the things we need for scala so we don't have to copy-paste the scala setup for the ctx).

if JavaInfo in dep_target:
java_provider = dep_target[JavaInfo]
current_dep_compile_jars = java_provider.compile_jars
current_dep_transitive_compile_jars = java_provider.transitive_compile_time_jars
runtime_jars.append(java_provider.transitive_runtime_jars)
else:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again the whole conditional as above but even if I’m wrong why silently ignore and not fail?

@johnynek
Copy link
Member Author

okay, @ittaiz I think I've addressed your comments. Thanks for the quick look!

Copy link
Member

@ittaiz ittaiz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m concerned about the “if”.
Previously we supported http_file, now we don’t but it’s not explicit.
People will not easily know.
For us (Wix) specifically this isn’t a problem but I’m concerned for the wider population.
Wdyt?

@ittaiz
Copy link
Member

ittaiz commented Jun 20, 2018

I have a thought,
Wdyt about adding a Boolean attribute until #510 is solved which opts in to this new behavior and once 510 is solved we’ll just enforce this requirement (by explicitly adding required providers)

@johnynek
Copy link
Member Author

@ittaiz I’ll try that tomorrow. Maybe the same approach to not generate the java jar when we know we don’t need it.

@johnynek
Copy link
Member Author

johnynek commented Jun 20, 2018

actually, @ittaiz I'd like to not yet fail and plumb the booleans through.

This will be a nontrivial change to wire that optionality down to the bottom of several collection methods and it is throw away work. Next, several places in the code were already lax in that they probed for expected shape and ignored things that don't match the shape.

Let's steer towards requiring providers at the bazel level and not probe anywhere, directly access dep[JavaInfo].

Can we merge this as is to unblock?

Copy link
Member

@ittaiz ittaiz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last suggestion- wdyt about adding at least a bold paragraph to the readme saying we silently ignore jars that have no JavaInfo (for example //jar:file)? We can remove the comment when we require providers

@ittaiz
Copy link
Member

ittaiz commented Jun 20, 2018

I approved btw as a way to say that if you feel strongly about not adding the comment to the readme then you can merge as is

@johnynek
Copy link
Member Author

okay, @ittaiz one more round... I added comments and went ahead and locked down runtime_deps, which scrooge does not use.

@johnynek johnynek merged commit afa6403 into master Jun 20, 2018
@ittaiz
Copy link
Member

ittaiz commented Jun 21, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants